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REMARKS 

In the Office Action dated April 14, 2004, claims 20, 28, 29, and 36 were rejected 
under 35 U.S.C. § 1 12, ^ 2; claims 1, 2, 5, 29, 32-34, 39, 43, and 45 were rejected imder 
35 U.S.C. § 102 over Culpepper, "SIP INFO Method for Event Reporting," draft- 
culpepper-sip-info-event-OO.txt (April 2000); claims 9-12, 18-21, 24, 25, 28, 35, 36, and 
40 were rejected under § 103 over Culpepper in view of Choudhuri, "SIP INFO Method 
for DTMF Digit Transport and Collection," draft-choudhuri-sip-info-digit-OO.txt (April 
2000); claims 13 and 23 were rejected under § 103 over Culpepper in view of Choudhuri 
and Media Gateway Control Protocol (MGCP), Version 1.0 (hereinafter "MGCP"); 
claims 3 and 30 were rejected under § 103 over Culpepper in view of MGCP; claims 4, 6- 
8, 14-17, 22, 26, and 27 were rejected under § 103 over Culpepper in view of Choudhuri, 
MGCP, and Bearer Independent Call Protocol (BICP) ITU Recommendation Q.1901; 
claims 31, 37, and 44 were rejected under § 103 over Culpepper in view of BICP; claim 
38 was rejected under § 103 over Culpepper in view of Donovan, "The SIP INFO 
Method," dated October 1999; and claims 41 and 42 were rejected under § 103 over 
Culpepper in view of Choudhuri and Donovan, 

As discussed in Apphcanfs previous Reply to Office Action, which is 
incorporated by reference here, Culpepper describes the use of the SIP INFO method for 
communicating mid-call events in SIP sessions or for carrying mid-session signaling 
messages. Culpepper at 1. As a result of this teaching of Culpepper, Apphcant explained 
that Culpepper relates to using a SIP INFO message to communicate information after a 
bearer path over a network has been established. 

In response to these arguments, the present Office Action made two points. First, 
the present Office Action stated that the term "call" can be construed broadly so that 
"mid-call" as described in Culpepper can be read upon the claimed element of receiving 
information before establishing a bearer path over a network. Such a construction is 
unreasonable in view of the objective evidence that existed at the time of the present 
invention, and based on explicit expressions of Culpepper itself The explicit statement 
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of Culpepper is that the SIP DSfFO message is used for communicating mid-call events in 
SIP sessions. Culpepper at 1. Going to the SIP Specification (RFC 2543), cited in 
Applicant's Information Disclosure Statement dated December 29, 2000, the term 
"session" is defined as a multimedia session that is a set of multimedia senders and 
receivers and the data streams flowing from senders to receivers" RFC 2543, at 10. The 
term "call" is used interchangeably by the SIP specification with the term "session." See 
RFC 2543, at 6 ("The Session Initiation Protocol (SIP) is an application-layer control 
protocol that can establish, modify, and terminate multimedia sessions or calls"). Thus, 
the SIP Specification provides objecfive evidence that a person of ordinary skill in the art 
at the time of the present invention would understand that the terms "session" or "call" as 
used in the SEP context, which is the context of Culpepper, refer to a connection in which 
a bearer path ("data streams flowing fi-om senders to receivers") has been estabhshed. 
Therefore, "mid-call" or "mid-session" as used in Culpepper must necessarily mean after 
a bearer path has been set up. 

Culpepper itself also cites to reference [4], E. Zimmerer et al., "SIP Best Current 
Practice for Telephony Interworking," IETF, October 1999 (copy attached). Reference 
[4] (Zimmerer) cited by Culpepper states that the "intent of the INFO method is to allow 
for SIP to carry session related control information that is generated during a session. 
The INFO method is added specifically to allow PSTN signaling messages beyond call 
setup and teardovra to be transmitted between MGCs." Zimmerer at 6. 

This statement in Zimmerer is consistent with the newly cited reference of the 
Office Action: Donovan, "The SIP INFO method," draft-ietf-sip-info-method-OO.txt 
(October 1999). Donovan also states that the INFO method "is to allow for the carrying 
of session related control information that is generated during a session" Donovan at 1. 
As explained by Donovan, "there is no general-purpose mechanism to carry session 
control information along the SEP signaling path during the session" Id. 

Thus, based on the objective evidence, it is clear that Culpepper contemplates the 
communication of information after a bearer path has been established (mid-call or mid- 
session). 

The Office Action fiirther made the second point that a person of ordinary skill in 
the art "must understand that in the voice over IP system, all of the signaling between two 
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end users is transmitted over a signaling system before establishing a connection path 
through data packet network." 4/14/2004 Office Action at 12. This statement, even if 
true, does not lead to the conclusion in the Office Action that Culpepper discloses 
"collecting DTMF digits by using SIP protocol in order to settip a call." Id, hi the SEP 
context, the call request to estabHsh a call session is the INVITE message. The INVITE 
message contains an identifier of the destination such as the INVITE message shown on 
page 122 of the RFC 2543 (the SIP Specification). In the example on page 122 of the 
SIP Specification, the SIP INVITE message contains the following address: sip: 
watson@boston.bell-tel.com. In the SIP context, the call request (INVITE) does not rely 
upon collection of DTMF digits, but rather contains a logical identifier of the destination. 
The statement in the Office Action (page 12) that DTMF digits are collected by the SIP 
protocol to set up a call is clearly erroneous-no such collection of DTMF digits is 
possible using the INVITE message, which is the message for establishing a call session 
in the SIP context. In fact, collection of DTMF digits for establishing a call is completely 
unnecessary, as the INVITE message contains a logical identifier that is sufficient for 
establishing the desired call between two endpoints. The DTMF digit collection referred 
to by Culpepper is a mid-session event, i.e., an event that transpires after the bearer path 
has been established between endpoints for the session. Thus, a person of ordinary skill 
in the art would not understand or recognize that SIP employs DTMF digits to establish a 
call. 

The Office Action further cited to page 6 (Section 6) of Culpepper of teaching the 
collection of digits "for estabUshing a call connection." 4/14/2004 Office Action at 3. 
Section 6 of Culpepper describes examples of a SIP INFO method that can be used to 
request DTMF digits be detected and reported. However, the SIP INFO method referred 
to in Section 6 is the SEP INFO method communicated in mid-cd\\ or m/J-session. As 
described in section 2 of Culpepper, the SIP INFO method is for "carrying DTMF digits 
generated during a session" This clearly does not satisfy the claim element "receiving 
the information before establishing a bearer path." 

Therefore, claim 1 is clearly not anticipated by Culpepper. Independent claim 29 
is similarly allowable over Culpepper. 
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Claims dependent from independent claims 1 and 29, including newly added 
dependent claim 46, are allowable over the cited references for at least the same reasons 
as corresponding independent claims. Claim 39, which depends from claim 1, recites that 
receiving the information comprises receiving the information in a Session Initiation 
Protocol Info message prior to establishing a bearer path over the network in response to 
the call request. Claim 39 recites subject matter that is contradicted by the teachings of 
Culpepper, which relates to receiving information in SIP INFO messages communicated 
along a SIP signaling path in mid-session or mid-call (i.e., after establishment of a bearer 
path). 

Claim 34, which depends from claim 29, is also allowable over Culpepper. Claim 
34 recites the establishing of a bearer path over the packet-based network after receiving 
the information — in contrast, in Culpepper, the information is received mid-session or 
mid-call, and thus, the bearer path has already been established. 

Moreover, claim 1 1 (which depends from claim 1), fiirther recites that requesting 
the information comprises requesting the information in response to determining that 
additional digits are desired to establish a call. Claim 1 1 was rejected as being obvious 
over Culpepper and Choudhuri. Neither Culpepper nor Choudhuri teaches or suggests 
requesting information in response to determining that additional digits are desired to 
establish the call. Both the proposed technique of Culpepper and the mechanism 
described in Choudhuri relate to mid-session or mid-call communication of the SIP INFO 
message for transporting DTMF digits. Both Culpepper and Choudhuri assume that a 
call has already been established-therefore, neither reference would determine that 
additional digits are desired to establish a call, and requesting information in response to 
such determining. The hypothetical combination of Culpepper and Choudhuri fails to 
teach or suggest the subject matter of claim 1 -therefore, a prima facie obviousness 
rejection has not been established with respect to claim L 

Independent claim 12 was rejected as being obvious over the asserted 
combination of Culpepper and Choudhuri. Claim 12 recites an apparatus that includes a 
controller to receive a call request from a media gateway controller, to determine if at 
least one digit is required to establish a call session, and to receive the at least digit from 
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the media gateway controller over the packet-based network from the media gateway 
controller in response to determining that the at least one digit is required. 

Note that claim 12 recites detemiining if a digit is required to establish a call 
session, and to receive such digit for establishing a call session from the media gateway 
controller. This implies that the determining and receiving acts are performed prior to 
establishment of a call session. As noted above, Culpepper teaches using the SIP INFO 
message for communicating mid-call events in SEP sessions. The Office Action cited 
Section 6 of Culpepper as teaching the collection of digits "for establishing a call 
connection." 4/14/2004 Office Action at 5. Section 6 makes no reference of collecting 
DTMF digits with SEP INFO methods for establishing a call session. As discussed above, 
the collection of the DTMF digits in Culpepper is performed mid-call, i.e., after the call 
connection has been established. 

Choudhuri also describes using SIP INFO messages to perform mid-session 
signaling. Choudhuri at 1-2. Therefore, even if the asserted combination of Culpepper 
and Choudhuri is proper, such a combination does not teach or suggest determining if a 
digit is required to establish a call session and receiving that at least one digit from a 
media gateway controller in response to determining that the at least one digit is required. 

The Office Action fixrther stated that "[i]t would have been obvious to one of 
ordinary skill in the art at the time the invention was made to apply collection method 
disclosed by Choudhuri into Culpepper's system in order to control a call between a 
calling party and a called party over Data network by using DTMF signal." 4/14/2004 
Office Action at 5. Note that claim 12 does not refer merely to the "control" of a call- 
claim 12 recites determining if at least one digit is required to establish a call session. 
The mid-call or mid-session communication performed by Culpepper and Choudhuri has 
nothing to do with establishing a call session. Therefore, the hypothetical combination of 
Culpepper and Choudhuri fails to disclose or suggest the claimed invention. A prima 
facie case of obviousness has thus not been established with respect to claim 12. 

Claims dependent from independent claim 12 are allowable over the cited 
references for at least the same reasons as claim 12. Moreover, claim 15, which 
indirectly depends from claim 12, fiirther recites that the controller is adapted to request 
the at least one digit from the media gateway controller over the packet-based network in 
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response to determining that the at least one digit is required to establish the call session. 
Contrary to the assertion made in the Office Action, neither Culpepper nor Choudhuri 
discloses a controller to request the at least one digit fi-om the media gateway controller 
over a packet-based network in response to determining that the at least one digit is 
required to establish the call session. 

The Office Action stated that "Culpepper discloses on pages 2 and 7, second 
paragraph that the use of a Package designator in the event request also helps reduce any 
ambiguity in which media source event detection and reporting is desired for. Therefore, 
it implies that the system adapts with a packet-based network for requesting digits fi-om 
the media gateway . . 4/14/2004 Office Acfion at 8. However, such a teaching has 
nothing to do with a controller requesting the at least one digit fi-om the media gateway 
controller over the packet-based network in response to determining that the at least one 
digit is required to establish the call session, as recited in claim 15. Although claim 15 
was rejected as being obvious over Culpepper, Choudhuri, MGCP, and BICP, the Office 
Action provided no explanation regarding how the MGCP and BICP references cure the 
defects of Culpepper and Choudhuri, The obviousness rejection of claim 15 fails for this 
fijrther reason. 

Claim 18, which depends from claim 12, recites that the controller is fiirther 
adapted to complete a call session in response to receiving the at least one digit. The SIP 
INFO messages exchanged in mid-session described in Culpepper and Choudhuri cannot 
satisfy this element. 

Claim 41, which depends indirectly from claim 12, was rejected as being obvious 
over Culpepper, Choudhuri, and Donovan. Claim 41 recites that the controller is adapted 
to receive at least one digit in a Session Initiation Protocol Info message prior to 
establishing the call session. This is contradicted by the teachings of Culpepper and 
Choudhuri. Donovan was cited by the Office Action as sending an lAM message- 
however, claim 41 does not recite an lAM message. Therefore, it is unclear what 
relevance Donovan has with respect to claim 41. The obviousness rejection of claim 41 
is thus also defective. 

With respect to dependent claim 42, which depends from claim 41, neither 
Culpepper nor Choudhuri discloses receiving a digit in a SIP Info message prior to the 
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controller sending a SIP OK message. This missing element is also not taught or 
suggested by Donovan. Therefore, the obviousness rejection of claim 42 over Culpepper, 
Choudhuri, and Donovan is also defective. 

Independent claim 20 was also rejected over the asserted combination of 
Culpepper and Choudhuri. Claim 20 recites that prior to a call session being estabUshed 
in response to a call request, a controller is adapted to receive a request to collect digits 
from a media gateway controller over a packet-based network. As noted above, 
Culpepper and Choudhuri teach communicating events during (not prior to) call session 
establishment. Therefore, the hypothetical combination of Culpepper and Choudhuri 
does not teach or suggest this element. A prima facie case of obviousness has thus not 
been established with respect to claim 20. 

Claims dependent from independent claim 20 are allowable over the cited 
references for at least the same reasons as claim 20. Moreover, claim 26, which depends 
from claim 20, recites that the controller is adapted to transmit the digits within a Session 
Initiation Protocol message prior to the call session being established. The Session 
Initiation Protocol Info messages used by Culpepper and Choudhuri are communicated in 
mid-call or mid-session, that is, after a call session has been established. Claim 26 was 
rejected over Culpepper, Choudhuri, and MGCP, and BICP. Claim 26 does not recite the 
lAM message referred to in the Office Action-therefore, it is imclear what relevance the 
MGCP and BICP references have with respect to claim 26. 

Independent claim 37 was rejected over the hypothetical combination of 
Culpepper and BICP. Even if the asserted combination of Culpepper and BICP is proper, 
such a combination does not teach or suggest receiving at least one digit in one of a BICC 
and Session Initiation Protocol message from a media gateway controller before 
establishing a voice path over a packet-based network. A prima facie case of 
obviousness has thus not been estabhshed with respect to the claim. 

Claims dependent from independent claim 37 are allowable over the cited 
references for at least the same reasons as claim 37. Moreover, with respect to claim 44, 
which depends from claim 37, neither Culpepper nor BICP discloses receiving a digit in a 
SIP Info message prior to establishing a call session in response to an Invite message. 
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In view of the foregoing, it is respectfully submitted that all claims are in 
condition for allowance, which action is respectfully requested. The Commissioner is 
authorized to charge any additional fees, including extension of time fees, and/or credit 
any overpayment to Deposit Account No. 20-1504 (NRT.0075US). 



Respectfully submitted, 



Date: July 14. 2004 
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Status of this Memo 

This document is an Internet -Draft and is in full conformance 
with all provisions of Section 10 of RFC 2026. Internet -Drafts are 
working documents of the Internet Engineering Task Force (IETF), its 
areas, and its working groups. Note that other groups may also 
distribute working documents as Internet-Draf ts . 

Internet-Drafts are draft documents valid for a maximum of six 
months and may be updated, replaced, or obsoleted by other 
documents at any time. It is inappropriate to use Internet- 
Drafts as reference material or to cite them other than as 
"work in progress." 

The list of current Internet-Draf ts can be accessed at 
http : / /www . ietf . org/ ietf /lid-abstracts . txt 

The list of Internet-Draf t Shadow Directories can be accessed at 
http : / /www . ietf . org/ shadow . html . 

Abstract 

This document describes Inter Media Gateway Controller (MGC) 
communication using the Session Initiation Protocol (SIP, 
[1]). SIP, with certain extensions, facilitates the exchange 
of signaling information between an Originating MGC and a 
Terminating MGC to complete calls. This document describes 
the best current practice for using SIP to perform this 
function. Where possible this draft references necessary 
documents, and details the concepts and methods of 
encapsulating PSTN signaling information in SIP messages. 

Zimmerer, et al draft-zimmerer-sip-bcp-t-OO.txt [Page 1] 



Note: 

This document obseletes the »SIP+: Inter-MGC Protocol'. 
The ideas expressed in the SIP+ document have now taken 
the shape of the SIP BCP-T. 

1. Introduction 
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This document describes Inter Media Gateway Controller 
communication using SIP[1] . SIP can be used to communicate 
from a SIP end-point (Note: Here, 'SIP end-point' has to be 
interpreted as a non-MGC SIP User Agent) to another SIP 
end-point, from a SIP end-point to a Media Gateway 
Controller (MGC) , and from one MGC to another MGC. This 
document details how to best use SIP to communicate 
from one MGC to another MGC. 

This document DOES NOT describe a new protocol. The 
intention of this document is to detail or reference 
the methods, standards and tools necessary to enable 
MGCs to interoperate via the SIP protocol. The SIP 
BCP-T replaces SIP+ (which was unfortunately viewed 
as being a new protocol) . The SIP BCP-T describes 
the best current practice for using SIP for Inter-MGC 
communication . 

The SIP BCP-T facilitates the exchange of information 
between an Originating Media Gateway Controller and 
a Terminating Media Gateway Controller so that calls 
may be completed. When SIP is used in the MGC-to-MGC 
space, there are many cases where it must "bridge" PSTN 
networks with IP networks. To do this, SIP must be extended 
to transport PSTN signaling information. By extending SIP 
messaging, and adding PSTN signaling encapsulation 
functionality, the SIP BCP-T satisfies the requirements 
for MGC-to-MGC communication. 



SIP provides the methods to set up, tear down and manage 
voice and data sessions. The extensions described and/or 
referenced in this document enable SIP to encapsulate a 
variety of PSTN signaling types including but not limited 
to SS7, and Q.931. 



Zimmerer, et al draft-2immerer-sip-bcp-t-OO.txt [Page 2] 
Internet Draft SIP-BCP-T Oct 99 



+ + + + + + 

I |<--SIP--->| Proxy |<--SIP--->1 I 

+ MGC I + + I MGC + 

I I |< SIP-- >| I 

I + + + + I 

SSI I ! 

Signal | I Signal 

Link + + IP + -| 

I I MG I Network | MG I I 

I + + + + I 

I I \ /II 



http://www.softannor.com/wgdb/docs/draft-zinunerer-sip-bq3-t-00.txt 



7/9/2004 



Page 3 of 10 



Q.931 trunk 



CAS tnink 



SS7 trunk \ 



/ SS7 trunk | 



\ 



+ 



+ 



+ - - 



-I 



PSTN 



+ 



+ 



+ 



Figure 1: Use of the SIP BCP-T 



Figure 1 shows a basic network configuration using SIP BCP-T. 
In this example Media Gateways are connected to the Public 
Switched Telephone Network (PSTN) via SS7 trxinks, Q.931 trunks, 
and Channel Associated Signaling (CAS) trunks. The Originating 
Media Gateway Controller may receive a call over any of these 
trunks. The signaling information from these trunks must be 
processed by the MGC to establish the originating half of the 
call, and to determine the identity of the Terminating MGC 
required to complete the call. The originating MGC uses SIP 
to communicate the necessary information to the terminating 
MGC to complete the call. The terminating MGC must be able to 
establish the terminating call half on any of the supported 
trunk types. 

The PSTN has many regional and national signaling variants 

which make interoperability difficult. A key design goal of 

the SIP BCP-T is to document a single standard method for MGCs 

to interoperate. Therefore, the SIP BCP-T will use international 

digit analysis, dialing plans, and interoperability standards 

from the PSTN rather than any single National or regional variants. 

TO guard against regional variations, the SIP BCP-T is being designed 

for international use from the start. The basic method of routing 

calls will use ITU-T E.164 [2] numbering, and will adhere to 

international routing of telephone numbers. 
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The SIP BCP-T focuses on commxinication between MGCs, but must also 
address the security concerns of SIP end-points communicating 
with MGCs. The information contained in MGC-to-MGC messages is 
sensitive, and must be secured from SIP end-points accessing 
the network. 

The SIP BCP-T reflects the design goals of .efficient call setup and 
scalability. This document describes a SIP implementation that is 
intended to scale to millions of calls per hour for a world-wide 
network. In addition to these ambitious goals, SIP BCP-T must 
facilitate "bridging" PSTN networks with IP networks. To do this, 
SIP BCP-T must be capable of transporting PSTN signaling information. 
SIP BCP-T provides the methods for MGCs to set up, tear down and 
manage voice and data calls-. The extensions detailed here allow 
SIP to accommodate a variety of in bound and out bound PSTN 
signaling types including but not limited to SS7, Q.931, and CAS, 

2. SIP BCP-T Components 

2.1. SIP as defined in RFC 2543. 
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2.2. MIME multipart 

Encapsulating PSTN signaling is a major function of the SIP BCP-T. 
MIME multipart payloads enable SIP to carry any PSTN signaling 
information required. SIP BCP-T uses MIME multipart [7-11] 
(RFCs 2045-2049) to enable SIP messages to contain multiple 
payloads in the body of the message. The multipart body 
can consists of any combination of the following units: 

SDP (Session Description Protocol) payload 

ISXJP payload 

One or more units of any MIME type payload. 

The following are the suggested encoding formats for the above- 
mentioned units: 

a) the SDP payload (text) : 

Content-Type: application/SDP; charset : ISO-10646 

The SDP [3] payload is plain- text. Although the default for plain- 
texts in MIME is US-ASCII, ISO-10646 is recommended here for the 
following reasons: Both SIP and SDP use ISO 10646, and the ISO 10646 
character set with UTF-8 encoding can be considered a superset of 
the US-ASCII character set per RFC 2044 [12] . 
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b) the ISUP payload (arbitrary binary data) : 

Content-Type: application/ ISUP; version: one of (ETSIl, ANSI, 
etc) 

Content -Transfer -Encoding: binary 

Encapsulating SS7 and other PSTN signaling messages inside SIP BCP-T 
allows MGCs to be compatible with the PSTN. SIP BCP-T encapsulates and 
transmits the native signaling messages from one PSTN to another, 
essentially tunneling the PSTN signaling messages through the IP 
networlc. To this end, SIP BCP-T has been extended with application/ 
ISUP versions for several variants of ISUP. The use of ISUP 
encapsulation with Content -Type "application/ISUP" allows ISUP 
signaling messages to be tunneled between MGCs. The use of • version' 
allows differentiation between different ISUP variants. This enables 
the terminating MGC to recognize and parse the messages correctly, 
or (possibly) to reject the message if the particular ISUP variant 
is not supported. The idea here is to allow MGCs to specify a 
preference of version, so that the following scenarios are possible: 
"I only lilce application/ isup; version=ETSIl" or "I accept 
application/isup (but don't Icnow the details; I just pass them on to 
some other tool that uses them)". The tools detailed in this document 
allow MGCs to encpsulate any variant of ISUP. 



The MGC network architecture malces possible the direct 
connection of the originating MGC and the terminating MGC without 
intermediate MGCs. This maJces possible the scenario where 
an MGC in one country must be able to "speaJc" the ISUP variants o 
all other countries in order to complete calls, (as opposed to an 
intermediate international gateway MGC) . Alternatively, the 
given MGC could use only a superset ISUP protocol, or an agreed 
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-upon "lowest common denominator" ISUP variant, which all 
other MGCs connected to that MGC would have to use. The 
ability to encapsulate any version of ISUP inside SIP messages 
enables any of these scenarios. The optimal interworking of protocol 
variants can be determined by the network operator. A superset 
approach, an agreed upon (lowest common denominator) interworking 
variant approach, or support of all variants approach can all be 
implemented using the SIP BCP-T. 

For example, when a call arrives at an MG on an SS7 trunk, the 
Originating MGC encapsulates the lAM in the INVITE 
message body that is sent to the terminating MGC. This MGC reads 
the lAM from the INVITE payload and may use it when creating its 
signaling message to the terminating telephone network. 

Zimmerer, et al draft-zimmerer-sip-bcp-t-OO.txt [Page 5] 

Internet Draft ; SIP-BCP-T Oct 99 

Subsequent ACM and ANM messages are passed back to the Originating 
MGC along with other necessary information via 100 Trying and 200 
OK messages. The version tells the receiving MGC which type of 
ISUP message has been encoded. 

Note: 100 responses aren't forwarded by intermediate servers and 
this constitutes a problem while trying to encapsulate the ISUP 
ACM. One method to get around this is to introduce a new 100 
class message that would go right upto the originating MGC, and 
use this to carry the ACM. It should be noted that this idea 
is still in a nascent stage and warrants more discussion at this 
point of time. Efforts are on to determine whether a proposal to 
deal with this currently exists, or if the formulation of a new 
one is necessary. 



c) One or more units of any MIME type payload 
(dependent on use) : 



No rules have been defined here. The Content-Type and 
Content -Transfer-Encoding parameters would be determined by the 
MIME type and the kind of data sent compliant with the rules of 
RFCs 2045, 2046. 

Note: The Content-Type specification is mandatory in all instances 
to differentiate between the different payload types. This is because 
there is no guarantee of a specific order or required type of the 
payloads . 

2.2.1 An illustrative example: 

SIP message format requires a Request line followed by Header lines 
followed by a CRLF separator followed by the message body. To 
illustrate the use of multipart payload message body, below is 
an INVITE message which has the originating SDP information and 
an encapsulated ISUP lAM: 

INVITE sip: 13035553142@Denl.level3.com SIP/.2.0 
From: sip : 1303 5553355@den3 . Ievel3 . com 
To: sip: 13035553142®Denl . Ievel3 .com 
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Call-ID: DEN1231999021712095500999@Denl. levels .com 
Content -Length: 377 

Content-Type: multipart/mixed; bo\indary=unique- boundary -1 
MIME -Vers ion: 1.0 

--unique -boundary- 1 

Content-Type: application/SDP; charset=ISO-10646 
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v=0 

o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4 

s=SDP seminar 

c=IN IP4 MG122.level3.com 

t= 2873397496 2873404696 

m=audio 9092 RTP/AVP 0 3 4 

- -unique -boundary- 1 

Content - type :applicat ion/ ISUP; version=ETSIl 
Content -Transfer-Encoding : binary 

39 8b Oe 95 le le le 06 26 05 Od f5 01 06 10 04 00 



- -unique -boundary- 1 - - 



Note: 

Since binary encoding is used for the ISUP payload, each byte is 
encoded as a byte, and not as a two -character hex representation. 
Hex digits were used in the draft because a literal encoding of 
those bytes would have been confusing and unreadable. 

2.3. ISUP MIME Type 

The ISUP MIME type is required to encapsulate the PSTN ISUP signaling 
information. See Internet draft: draft-zimmerer-sip-isup-mime-OO.txt 
[4] 

2.4. INFO method 

The intent of the INFO method is to allow for SIP to carry session 
related control information that is generated during a session. 
The INFO method is added specifically to allow PSTN signaling messages 
beyond call setup and teardown to be transmitted between MGCs . This 
method may be used by either originating or terminating MGC to 
communicate additional information such as mid-call telephony 
signaling messages resulting from the interworking between an ISUP 
or ISDN network device and a SIP controlled network. 

This has been described in an Internet Draft: 
draft-ietf-mmusic-sip-info-method-01.txt . [5] 

Note: This draft references draft-ietf-sigtran-mime-isup-OO.txt 
proposal for encapsulating telephony signaling control information as 
part of an ISUP attachment to the INFO message. It is recommended to 
use the format outlined above in section 2.2. MIME Multipart instead. 

2.5. ISUP-SIP mapping 
(Internet draft pending) 

The SIP BCP-T recommends the ISUP-SIP mapping detailed m the 
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Internet draft: draft-camarillo-mmusic-sip-isup-bcp-OO.txt. 
[61 . 
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2.6. Network Access Point (NAP) architecture 
(Internet draft pending) 

3 . Security 

The security provided by SIP is sufficient for the initial deployment 
of inter-MGC communication. There are issues requiring further study 
with regard to the interoperation of MGCs and SIP end-points. There 
is an interesting line that must be drawn between giving too much 
control to the endpoint clients and not enough control. The notion 
of a secure proxy between SIP end-points and the network MGCs 
requires more study. 



4. Glossary 



ACM 



ANM 



CAS 



Address Complete Message. One of the ISUP call setup 
messages. A message sent in the backward direction 
indicating that all the address signals required for 
routing the call to the called party have been received. 

ANswer Message. Another one of the ISUP call setup 
messages. A message sent in the backward direction 
indicating that the call has been answered. 

Channel Associated Signaling. Signaling (for example, 
T-1 line) in which control signals, are carried 



in a 



m 



the same channel along with voice and data signals. 



lAM 



ISDN 



ISUP 



Initial Address Message in the ISUP call set up 
messages. A mandatory message sent in the forward 
direction to initiate seizure of an outgoing circuit. 

Integrated Services Digital Network in concept is the 
integration of both analog or voice data together with 
digital data over the same network. 

ISDN User Part. This defines the methods and protocols 
used in the establishment and tear-down of voice and 
data calls over the public switched network, and to 
manage the trunk network on which they rely. It is 
used for both ISDN and non-ISDN calls. 

Media Gateway Controller. Also known as a Call Agent 
or a Softswitch. This is the unit that controls the media 
gateways and is responsible for all the control signaling 
necessary for call set-up. 

Zimmerer, et al draft-zimmerer-sip-bcp-t-OO.txt [Page 8] 
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MIME Multipurpose Internet Mail Extensions. This set of 

documents redefines the format of mail messages to 
allow for multipart message bodies, textual message 



MGC 
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bodies and header information in character sets other 
than US -ASCII, etc. 

PSTN Public Switched Telephone Network. It refers to the 

world's collection of interconnected voice-oriented 
pxiblic telephone networks, both commercial and 
government - owned . 

SDP Session Description Protocol. It is a protocol that is 

used to transfer information between interested parties 
to discover and participate in a multimedia session. 
Fully specified as a standard in RFC 2327 ([3]). 

SIP BCP-T Best Current Practices for using SIP in Telephony. It is , 
an extension of SIP (as specified in RFC 2543) to 
facilitate inter-MGC communication. 

SS7 Signaling System 7. It is a global standard for tele- 

communications that defines the architecture for performing 
the call -establishment, billing, routing, and information- 
exchange functions of the PSTN. 

Q.931 This ITU-T recommendation is the signaling protocol in 

the PRI ISDN D channel. It describes what goes into a 
signaling packet and defines the message type and content. 

UTF-8 Unicode Standard Transformation Format. This is a 

transformation format that retains the full US-ASCII 
range and provides compatibility with file systems, 
parsers and other software that rely on US -ASCII 
values but are transparent to other values . 
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